Communication systems continue to grow and evolve. Convergence between different types of communication systems, e.g., Internet Protocol (IP), connection-based voice communications, and the like, is advancing rapidly. Recently the phrase “Next Generation Network” (NGN) has been used to describe various activities associated with this evolution. As defined by the International Telecommunications Union (ITU), an NGN is a packet-based network able to provide services (including telecommunication services), able to make use of multiple broadband, Quality of Service (QoS)-enabled transport technologies and in which service-related functions are independent from underlying transport-related technologies. NGNs will also likely offer unrestricted access by users to different service providers and will support generalized mobility, which in turn will provide for consistent service provision to end users.
Various standardization groups are working on reaching a consensus regarding the technology considerations which will affect NGN design and implementation. For example, Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN) is a European Telecommunications Standards Institute (ETSI) standardization group which focuses on convergence of technologies used in the Internet and other fixed networks. Among other things, TISPAN seeks to provide a modular, subsystem-oriented architecture which facilitates the addition of new subsystems over time to cover new demands and service classes. The TISPAN architecture attempts to ensure that network resources, applications, and user equipment are common to all of the various subsystems to provide for enhanced mobility across, for example, administrative boundaries.
One of the TISPAN subsystems is referred to as the Network Attachment Sub System (NASS). The NASS is responsible for, among other things, handling configuration information, user authentication data, Internet Protocol (IP) address allocation and registering associations between IP addresses allocated to user equipment (UE) and related network location information. An exemplary architecture is illustrated in FIG. 1, which is similar to FIG. 5.1 in the ETSI standards document entitled “Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Functional Architecture; Network Attachment Sub-System (NASS)”, ETSI ES 282 004 V1.1.1 (2006-06). This exemplary architecture illustrates a NASS and some of the external elements that exchange communications with elements within a NASS. A brief discussion regarding the functional entities shown in FIG. 1 is provided below, however the reader interested in more details is directed to the foregoing standards document. Additionally, in FIG. 1, the links between the various entities represent interfaces. Those interfaces in the NASS which have a lowercase letter and number combination associated therewith (e.g., “e2” and “a3”) refer to standardized interfaces discussed in the foregoing standards document. Other interfaces, e.g., Pq and Gq′, are used outside of the NASS and are shown where relevant.
For example, the Connectivity Session Location and Repository Function (CLF) 10 operates to, among other things, register the association between the IP address allocated to the UE 12 for a connection and related network location information provided by the Network Access Configuration Function (NACF) 14, such as access transport equipment characteristics, line identifier (Logical Access ID), IP Edge identity, etc. The NACF 14 thus operates to allocate IP address(es) to the UE 12 and may also provide other network configuration parameters, such as the address of DNS server(s) and the address of signaling proxies for specific protocols. The CLF 10 is also in communication with the Resource and Admission Control Subsystem (RACS) 16, other service control subsystems and applications 18, and the User Access Authorization Function (UAAF) 20. The UAAF 20 performs user authentication and authorization checking based on user profiles for network access. The UAAF 20 retrieves authentication data and access authorization information from user network profile information contained in the Profile Database Function (PDBF) 22.
The RACS 16 includes an Access-Resource and Admission Control Function (A-RACF) 34 and a Service-based Policy Decision Function (SPDF) 36. The RACS 16 acts as an interface between the NASS and AF 38 for delivering policy based transport control services, e.g., resource reservation, at a certain time for a specific application. The functional elements within RACS 16 are used to support these policy based transport control services. More specifically, the A-RACF 34 supports admission control and network policy assembly, whereas the SPDF 36 is a logical policy decision element and performs functions, such as, receiving and checking resource request information and insulates the AF 38 from the transport layer. More information regarding RACS 34 can be found in “Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Resource and Admission Control Sub-system (RACS); Functional Architecture, ETSI ES 282 003 V1.1.1 (2006-06).
The Access Management Function (AMF) 24 translates network access requests issued by the UE 12 and forwards those requests for allocation of an IP address and, optionally, additional network configuration parameters to/from the NACF 14. The AMF 24 also forwards requests to the UAAF 20 to authenticate the user, authorize or deny network access, and retrieve user-specific access configuration parameters. The NASS architecture further includes an Access Relay Function (ARF) 26 acting as a relay between the Customer Network Gateway (CNG) 28 and the NASS which inserts local configuration information.
As shown in FIG. 1, the UE 12 can be functionally divided into the terminal equipment (TE) 30 itself and the CNG 28. The CNG 28 receives configuration data from the CNG Configuration Function (CNGCF) 32. More specifically, as stated in the above-identified standards document, the CNGCF 32 is used during initialization and update of the CNG 28 to provide the CNG 28 with additional configuration information (e.g. configuration of a firewall internally in the CNG 28, QoS marking of IP packets etc.), which configuration data differs from the network configuration data provided by the NACF 14.
Utilizing the above described elements, an external AF 38 can reserve transport resources from the access network on behalf of a user. One method for performing this process is for the AF 38 to contact the known address of the serving network's CLF 10 over the e2 interface to obtain the address of the specified SPDF 36. The AF 38 then contacts the specified SPDF 36 over the Gq′ interface with the user information and the required QoS characteristics for the desired service. The SPDF 36 then contacts the A-RACF 34 to reserve the appropriate resources. A problem with this existing solution occurs when there are multiple A-RACFs 34 with which an SPDF 36 can communicate for serving an access area. In this case the SPDF 36 will not necessarily know which A-RACF 34 to communicate with to support a given request from an AF 38. One possible solution regarding how to identify an appropriate one of the multiple A-RACFs 34, would be to establish static IP address domains for each A-RACF 34. However, this solution may not be optimal due to the lack of flexibility associated with the provision of static IP addresses. Also note that while FIG. 1 does not show multiple A-RACFs 34 with different IP address domains, it is to be understood that there could be multiple A-RACFs 34 with different IP address domains with which the SPDF 36 is in communication with.
However, no efficient mechanism or technique is currently available for enabling an SPDF to determine which of a plurality of A-RACFs serving an access area should be used to handle a given access request.